Summary

• Adds infrastructure for custom JS objects to support structured cloning via postMessage/MessageChannel
• Objects set [core.hostObjectBrand] to a serializer function returning { type: "<name>", ...data }, then register a deserializer via core.registerCloneableResource(name, fn)
• Marks op_deserialize as reentrant so deserializer callbacks can invoke ops
• Passes registered cloneable deserializers during message port deserialization

This enables objects like CryptoKey (#12734) and X509Certificate to be cloned across message ports, addressing #12067.

For reference, here's how this approach compares to Node.js's implementation of structured cloning for custom objects:

Node.js approach

• Hooks into V8's serializer delegate at the C++ level (src/node_messaging.cc — WriteHostObject/ReadHostObject)
• Objects call markTransferMode(this, cloneable, transferable) which sets a private symbol with bitflags (kCloneable = 0x1, kTransferable = 0x2)
• During serialization, the delegate calls obj[kClone]() which returns { data, deserializeInfo: "module:ClassName" } (e.g. "internal/crypto/keys:InternalCryptoKey")
• During deserialization, uses dynamic require() module loading to discover the constructor from the deserializeInfo string — no explicit registry needed
• Two-phase deserialization: first creates an empty instance via the constructor, then calls obj[kDeserialize](data) to populate it
• Supports both C++ BaseObjects (via virtual methods) and JS objects (via symbols) in a unified framework

Our approach

• Hooks into the same V8 mechanism but from the Rust/JS side — [core.hostObjectBrand] symbol triggers write_host_object/read_host_object in ops_builtin_v8.rs (this infrastructure already existed)
• Objects set [core.hostObjectBrand] to a serializer function that returns { type: "<name>", ...data }
• Uses an explicit registry (core.registerCloneableResource(name, deserializerFn)) mapping type name → deserializer function
• Single-phase deserialization: the deserializer function creates and returns the final object directly (simpler, no separate create/populate phases)

Ref: #12067
Ref: #12734